This specification relates generally to software development tools, and more specifically to the use of code postprocessing to update application bytecode without losing application state information
Software developers often program iteratively. A developer writes some code, performs a build process on the code, deploys and initializes the code, and then runs the code to test it out. The developer can then go back make some changes and iterate through this process again. If the developer is able to iterate quickly, he or she can try out many ideas to understand how a system works and converge on a good solution relatively quickly.
The build/deploy/initialize parts of the process mentioned above can be relatively quick in some development environments, and can take longer in others, on the order of a few minutes if not longer. While this delay is generally acceptable for some developers and development environments, it is not acceptable in others.
Some execution platforms allow an application to be modified while it is running under very limited circumstances. For example, the JAVA VIRTUAL MACHINE (JVM) supports a limited form of updating the code of methods, known as method replacement. The JVM does not directly support the ability to make arbitrary changes to the code of a running application, such as changes to the class hierarchy, fields, and methods. Extension platforms such as JREBEL do allow live code modification, but they rely on making changes to the underlying execution platform (the JVM for JREBEL). Further, these modified execution platforms do not provide any support for mobile hardware platforms, such as Android.
Relatedly, systems such as the Open Services Gateway initiative (OSGi)s and some JVM or Common Language Runtime (CLR)-based web frameworks support faster restarting of components of a program. However, restarting a software component loses all objects from a previous iteration of the component unless the component was explicitly designed and coded to save and restore its state.